ECS on EC2におけるスケーリングの辛みを「Capacity Provider」で解決する

島川寿希也

2020.03.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは。コンサル部の島川です。

2019年12月頭にECSの新機能であるAWS ECS Cluster Auto Scalingが発表されました。略してCAS。AutoScalingGroupにECS専用ポリシーが紐づけされます。これは同時期にリリースされた「Capacity Provider」と一緒に使う必要があります。ただ...めちゃくちゃ便利そうだという第一印象だけで実際にどういう動きをするのか、何が嬉しいのかという点についてモヤモヤしていた部分があったので実際に手を動かしてみて動きを確かめてみました。

結論からECS on EC2を運用されている方は「Capacity Provider」を有効にしてCASを使うメリットが大きいです。EC2のスケーリングをほとんど考えなくて良くなります！

ECS on EC2における今までの課題

今までは

EC2のスケーリング
AutoScalingGroupの管理
Taskのスケーリング
サービス定義の管理

の2つのスケーリングについて考慮する必要がありました。Taskの増減に合わせてEC2の数を調整する必要があったので、CloudWatchのカスタムメトリクスを作成してスケーリングポリシーを組んだり、Lambdaで管理したりと対応することの難易度が高かったです。

Fargateに移行すれば解決できますが、なかなかそういったこともできなく結局のところEC2をある程度大きくしておいたり、スケーリングそのものをあきらめたりといったケースも多かったと思います。

CASとCapacity Providerで解決

そんなECS on EC2におけるつらみをCASとCapacity Providerは解決してくれます！タスクのスケーリングだけ意識すればよくなります。タスクのスケーリングに合わせてEC2のスケーリングもやってくれます。

CASはマネージドのスケーリングルールでタスクを起動する分のEC2がなければスケールアウトし、余分なEC2があればスケールインを自動的にやってくれます。

もう少し具体的に変更される設定値をお話しするとAutoScalingGroupの「希望するキャパシティ(Desired Capacity)」が「最小サイズ(Min Size)」～「最大サイズ(Max Size)」の範囲の中で変更されます。

実際の動きについて

いい感じにやってくれるのはいいけど、どんな動きをするのかについて簡単に検証してみました。（冒頭でお話したモヤモヤしている部分）

◆前提

t3.microのEC2を使用
ECSクラスター作成済み
Capacity Provider 設定済み
ターゲットキャパシティー % は 100%
AutoScalingGroupの設定済み
最大サイズ「10」に変更 ※希望するキャパシティが0になっていますが、スケールインの保護を実施しているため1台は起動している状態になります。

ここに512MBのメモリを使用するタスク(コンテナ)を起動します。t3.microのメモリサイズは1GBなので約半分使われる形になります。

タスクを増やした時の動き

この状態でタスクを2に増やします。

PROVISIONING状態になりました。

残りのメモリが445MBなので512MBのタスクを起動する分のリソースが足りないため、本来であればEC2を追加する必要があります。このままでは起動しませんが、自動でやってくれているはず...!ということでAutoScalingGroupの設定値を確認してみます。ECSのキャパシティープロバイダータブからも確認できます。

希望するキャパシティが「2」になっているのが確認できました！あとはEC2が起動して、タスクが配置されるのを待ちます。起動されました。タスクの設定変更を実施してからEC2の起動合わせて約3分間で完了しています。ここはEC2の起動設定の内容やコンテナサイズにもよるものなので、参考程度にしてください。

タスクを減らした時の動き

続いてタスクを2→1に戻しての動きを確認します。タスクが一つ停止されました。

EC2とAutoScalingGroupの設定はまだそのままの状態です。自動的にスケールインをするのを待ちます。

思った以上に時間がかかりました。設定変更から30分ほどかかっています。(見逃していたのでCloudTrailから確認しました。)

スケールインはサービス影響を伴う可能性のある作業なので少し慎重にやっているのかなという印象を持ちました。

検証まとめ

[スケールアウト]低サイズのコンテナであればEC2の起動を含めて約3分で実施できる
[スケールイン]タスクはすぐに停止されるがEC2は30分ほど経過してから削除される
タスク数の変更のみでよいことが改めて分かった

さいごに

改めてECS on EC2を利用されている方にはぜひ一度Capacity Providerを使ってほしいと思いました。スケーリングを考える部分が少なくなるというのは運用コストがかなり下がると考えています。手動で運用している場合でも設定箇所が減るメリットもあります。ただスケーリングポリシーがいじれないので実際に検証頂いて動き(かかる時間)を確かめていただいた上で設定を適用いただければと思います！

また今回のスケーリングポリシーについて(ロジック)はAWSが公開していますので一度読んでみると面白いかもしれません。 Amazon ECS クラスターの Auto Scaling を深く探る